According to a service-oriented architecture, a backend service layer provides services (i.e., business functionality) to service consumers, typically via Web protocols. FIG. 1 is a block diagram illustrating one such scenario. Typical service consumers use this business functionality to provide user interfaces, application-to-application or business-to-business integration, output management (e.g., printing), spreadsheet download, etc. Service consumers of different types, or even of a same type, may access the backend service layer in different ways. Therefore, the services are not particularly adapted to the requirements of any particular service consumer.
A backend service layer exposes complex services which may be used to orchestrate its underlying business logic. However, a developer of a user interface client application simply binds user interface data entities of a user interface data model to entities of the backend service layer, and then develops user interface logic (e.g., logic for computing user interface indicators or coloring/hiding fields) in terms of the user interface data model. That is, the developer is concerned only with user interaction and the exposure of data and events on the user interface, and is not concerned with orchestration of the underlying business logic.
Some operations of the user interface logic might require access to backend services. These UI requests typically require multiple service calls in the backend service layer, such as modification of data, execution of actions, saving, coping with pending modifications, value help request processing, reacting on data changes, retrieving data, retrieving properties, etc.
From a modeling perspective, a request sent by a user interface client application to the backend service layer corresponds to a backend operation contained inside an event handler. Execution of a backend operation will force a request from the user interface client application to a backend runtime, because the client data buffers and backend buffers are synchronized in order to show current data to the user.
An event handler can contain multiple backend operations, each of which may correspond to one or more service calls. Moreover, several complex change services may be executed in a chain and, after each operation, data will be read in the backend runtime and sent to the UI client runtime. This approach is undesirable because the net backend runtime consumption (i.e., time of roundtrip) must be considered as well as the amount of roundtrips in combination with the network latency. Therefore, in case the server is located in Germany and the user is located in China, a possibly high network latency of a client request will affect the overall performance negatively in case of many roundtrips.
Furthermore, the execution of the related backend services separately without regard to one another increases support and development complexity, since, for example, support engineers have to cope with separate code executions that logically belong together. Furthermore, the foregoing system involves redundant code execution for data retrieval, which the support engineers have to check as well.